The use of video display terminals is now common in data processing. Each such display terminal normally has at least a video monitor or liquid crystal display (LCD) and an operator keyboard. In addition, terminals may also contain other audio and/or visual output devices (e.g., alarms, etc.) and other manual input devices (e.g., joysticks, etc.).
Architecturally, display terminals may be divided into two categories. The more complex type may be termed multifunction or "smart" terminals. Such terminals have sufficient logic capability within the terminal to reconfigure and adapt to various different applications and to respond directly to various operator inputs. The advantage of this architecture is that the communication requirements between terminal and host computer are greatly reduced. Unfortunately, the additional logic in this type of terminal makes it more costly to build and maintain.
The second category of display terminal is the fixed function or "dumb" terminal. This type operates in a fashion where each keystroke or operator input is transmitted to and processed within the host computer. Since the display terminal has a minimum of logic, the cost is less than a smart terminal. Previous terminals of this type had a very limited command set with which the display controller software in the host computer could update the contents of the screen (e.g., basic moves, inserts, write between limits, read between limit commands, etc.). In addition, most previous fixed function terminals had a screen buffer the same size as the physical screen. This limits the display controller software to manipulating data only on the physical screen (usually 24 rows by 80 columns).
Fixed function display terminals tend to require more communication time because all the data is processed in the host computer. The communication requirement imposes a burden on the host computer and the terminal which it would be desirable to avoid.
One method known in the art for greatly enhancing the fixed function terminal is the addition of an attribute buffer. The attribute buffer is arranged within the display terminal such that each displayable character has one or more corresponding attribute(s) which may be specified by the attribute buffer. Specifiable attributes include color, blinking, underlining, etc.
To enhance performance and reduce complexity, fixed function terminals have display buffers which are addressed as one large sequential space. This means that data sent to the display buffer must be sequential and contiguous for each write operation. This is also true for receiving data from a fixed function terminal (i.e., read operation). As display buffers get larger (i.e., more characters are displayed) and more attributes are added, the performance of the fixed function terminal becomes limited by the time required to make the I/O transfers to and from this single large sequential space. Therefore, it becomes important to maximize the efficiency of such I/O transfers.
IBM Technical Disclosure Bulletin, Volume 24, Number 11A, dated April, 1982, entitled "Prefetch of Attribute Bytes in a Display Buffer", by G. A. Emerson, suggests that efficiency may be enhanced by coding field attributes and extended field attributes for easy detection. This permits intermixing characters within a single I/O transfer.
A further enhancement is proposed in IBM Technical Disclosure Bulletin, Volume 26, Number 103, dated March, 1984, entitled "CRT Display Feature Editing and Control", by D. A. Stockwell. This reference proposes alternating display and attribute characters within the I/O stream. This simplifies input/output operations by permitting a single write or read to access both the display buffer and extended attribute buffers of a terminal. The disadvantage of this approach is the requirement to transfer all characters within each I/O operation, even though many (in some cases, perhaps even most) character positions are blank.
Another attempted improvement is described in IBM Technical Disclosure Bulletin, Volume 26, Number 10A, dated March, 1984, entitled "Implementation of Field Inheritance", by P. A. Beaver, et al. This approach to the problem of blank characters is insertion of pad characters into the data stream. The problem with this technique is that these additional pad characters consume I/O time when inserted into the data stream.
All of these techniques provide less than optimal performance because of the transmission of excess blank characters and/or the reliance upon multiple I/O operations.
This problem is particularly acute in a word processing environment, although not limited to such an environment where the right end of line invariably ends in a number of spaces. These spaces are virtually meaningless, but must nevertheless be individually transmitted in prior art systems.